Distributed process control systems (“PCS”) or process control networks, like those used in chemical, petroleum, industrial or other process plants to manufacture, refine, transform, generate, or produce physical materials or products, typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog/digital buses, and/or via one or more wired and/or wireless communication links or networks, as well as other components. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment (which is interchangeably referred to herein as the plant environment, field environment, or front-end environment of the process plant), and generally perform physical or process control functions such as opening or closing valves, measuring process parameters such as pressure, temperature, etc. to control one or more industrial processes executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarming functions, and other control functions commonly implemented within a process controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute respective controller applications that run, for example, different control modules which make process control decisions, generate control signals based on the received information, and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in a process controller send the control signals over the communication links to the field devices to thereby control the operation of at least a portion of the process plant or system, e.g., to control at least a portion of one or more industrial processes running or executing within the plant or system. I/O devices, which are also located within the plant environment, typically are disposed between a controller and one or more field devices and enable communications therebetween, e.g., by converting electrical signals into digital values and vice versa. As utilized herein, the term “process control devices” generally refers to field devices, controllers, and I/O devices which are generally located, disposed, or installed in a field environment of a process control system or plant.
Still further, in many process or industrial plants, the process control network is coupled to a safety instrumented system (“SIS”) which operates to detect significant safety-related conditions, issues, or problems within the process control system and/or the process plant (e.g., an oscillation that is escalating in amplitude over time, a stream of values that are out of expected range, a portion of the process becoming uncontrolled, the occurrence of one or more conditions which might result in or lead to a serious hazard in the plant, such as a leak of toxic chemicals, a stuck valve, etc.). Safety instrumented systems support or service at least portions of the process control system within the process plant, communicate safety messages between devices and/or portions of the process plant in order to automatically trigger preventative or mitigating actions, such as closing or opening valves, removing power from devices, switching flows within the plant, tripping or placing one or more devices into safe mode, and/or other preventative or mitigating actions. Generally speaking, safety instrumented systems include one or more safety controllers which typically are separate and distinct from the process control controllers operating within the plant to control the process. SIS controllers may include one or more safety system logic solvers, which may be communicatively connected to safety field devices via safety buses, communication lines, links, wired networks, and/or wireless networks installed within the process plant, and, in some arrangements, may be communicatively connected to process control field devices and controllers. Typically, SIS devices such as SIS controllers, devices, logic solvers, etc. communicate with one another over safety communication buses, links, networks, etc. in a direct, point-to-point manner, e.g., at the I/O level of the process control system (for example, by using a message format that is utilized and/or implemented for communications by I/O cards included in the process control system), or other suitable communications level.
Safety system logic solvers execute respective safety information function (SIF) routines that receive and process respective input signals generated by other safety system logic solvers or controllers, safety field devices, process control field devices, and/or process control controllers, and that are indicative of various conditions such as, for example, value(s) of particular parameters, the position of certain safety switches or shutdown valves, overflows or underflows in the process, the operation of important power generation or control devices, the operation of fault detection devices, etc. A safety information function routine operates on the received inputs in accordance with its respective logic to determine whether or not the combination of received inputs is indicative of an occurrence of a safety-impacting or safety-related event (e.g., “safety events”) within the process plant, or probability thereof. A safety event may be detected or indicated by, for example, a single condition occurring in one portion of the plant, the simultaneous occurrence of two or more conditions in one or more portions of the plant, and the like. Generally speaking, although not necessarily, a “true” signal that is output by a safety function routine upon receiving multiple input signals and processing the inputs in accordance with the routine logic to generate the output is indicative of the occurrence of a safety event, or a significant probability thereof. When the occurrence of a safety event (or significant probability thereof) is detected, a safety controller takes some action to limit the detrimental nature of the event, such as sending control signals to close valves, turn devices off, remove power from devices and/or sections of the plant, etc. For example, a safety controller may send control signal(s) to force other devices or components into a tripped state or “safe” mode of operation designed to prevent or mitigate the effects of a serious or hazardous condition within the process plant.
Information from the field devices, the process controllers, and the safety system logic solvers (also called safety controllers) is usually made available over one or more data highways or communication networks to one or more other hardware devices, such as operator workstations, personal computers or other types of computing devices with user interfaces, data historians, report generators, centralized databases, or other centralized administrative computing devices that are included in the process control network and that are typically placed in control rooms or other locations away from the harsher field environment of the plant, e.g., in a back-end environment of the process plant. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run applications that enable a control or a safety system operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine or a safety routine, modifying the operation of the control modules within the process controllers, the safety system controllers, the field devices, etc., viewing the current state of the process, viewing alarms generated by field devices, the process controllers, or the safety system controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers, and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths. Typically, data highways/communication networks that transport control information generated by process control field devices and controllers are separate and distinct from data highways/communication networks that transport safety information generated by safety field devices and controllers, although in some configurations, at least some portions of a control data highway and a safety data highway may be integral or commonly implemented.
As an example, the DeltaV™ process control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more workstations or computing devices in the back-end environment of a process control system or plant, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which may be objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application also allows a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller (such as the process controllers and the safety system controllers) and, in some cases, one or more field devices, stores and executes a respective controller or safety application that runs the control modules assigned and downloaded thereto to implement actual process control and/or safety system functionality.
Moreover, one or more user interface devices, or plant display applications which are executed on one or more user interface devices, such as operator workstations, one or more remote computing devices in communicative connection with the operator workstations and the data highway, etc., receive data from the controllers and the field devices via the data highway(s) and display this data to process control system designers, operators, or users via a user interface screen. These user interface devices or applications provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. tailored to actions performed by different users in the plant. Moreover, a data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway(s) while a configuration database application runs in a still further computer attached to the data highway(s) to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
In long-haul process plant configurations (e.g., such as oil pipelines, offshore platforms, remote wellheads, etc.), interconnected portions of a field environment of the process control system may be situated or located remotely from one another (e.g., a great distance apart from one another, and/or separated by physical obstructions, barriers, or obstacles such as water, mountains, underground wells, etc.). For instance, one or more portions of the process control system may be geographically distant from the rest of the system, e.g., may be located underground while the rest of the system is located aboveground, located underwater while the rest of the system is on land, located miles away in the desert while the rest of the system is situated in a city, etc. However, safety conditions arising even in very remote portions of a process control system can in some instances affect the safety of other portions of the process control system at other locations and/or as a whole, and vice versa. Accordingly, in many cases, communicating safety messages between distant portions of a safety instrumented system that services the process control system is necessary to prevent plant hazards, such as toxic chemical spills, explosions, etc. and/or to prevent or mitigate the effects of even minor safety events. Currently known safety instrumented systems typically communicate safety messages between local portions of a process plant using local communication buses or local data highways, and typically communicate safety messages between portions of the process plant that are separated by long-haul distances (e.g., that are remotely located) by using higher-bandwidth links, such as satellites and fiber-optic cables. However, such high-bandwidth links are expensive to use and, in the case of satellite communications, rely on a third-party vendor. Moreover, for some lower rate, slow-communication safety messages (e.g., heartbeat messages, and the like), the amount of bandwidth provided by high-bandwidth links is overkill and thus their use is not a prudent financial decision. On the other hand, while a lower-bandwidth or otherwise “slower” transport link is less expensive to use for data transport between portions of a safety system that are separated by long-haul distances, typically a lower-bandwidth link does not efficiently and effectively transport large or frequently-generated safety messages over long-haul distances with sufficient fidelity and within the time constraints needed to maintain safe operations of a process plant.